European Accessibility Act: preparando junio de 2025

Pantalla de dispositivo con controles accesibles en alto contraste

La European Accessibility Act (EAA, Directiva 2019/882) entra en vigor el 28 de junio de 2025. Aprobada en 2019, traspuesta en los últimos años por los estados miembros, es ya una realidad inminente. Muchas empresas la tienen identificada pero no trabajada. Otras no saben que les aplica. Este artículo es un resumen práctico: quién está obligado, qué exige, y cómo planificar con margen para llegar a tiempo.

Qué es la EAA

La EAA armoniza los requisitos de accesibilidad de productos y servicios en toda la UE. Su objetivo es que personas con discapacidad puedan acceder a productos y servicios digitales y físicos sin barreras desproporcionadas. Los Estados Miembros han ido adaptando su legislación nacional; en España, el Real Decreto 193/2023.

No es nueva en espíritu — ya había normativa sobre sector público (WAD, Directiva 2016/2102). La EAA extiende obligaciones al sector privado.

Qué productos y servicios cubre

La lista es extensa y a veces sorprende:

Productos:

  • Ordenadores, smartphones, tabletas y sus sistemas operativos.
  • Terminales de autoservicio: cajeros automáticos, máquinas de billetes, totems de check-in.
  • Routers, decodificadores, smart TVs.
  • Lectores de libros electrónicos.

Servicios:

  • Comercio electrónico (e-commerce).
  • Servicios bancarios electrónicos.
  • Telecomunicaciones (llamadas, mensajería, acceso a emergencias 112).
  • Transporte (reserva online, pantallas de información, billetes electrónicos).
  • Libros electrónicos y software para leerlos.
  • Servicios de medios audiovisuales — interfaces de Netflix, Prime Video, etc.

Si tu empresa tiene e-commerce consumer en Europa, la EAA te afecta. Si tienes una app bancaria, te afecta. Si vendes un SaaS que los usuarios consumen en sus navegadores, probablemente también.

Excepciones importantes

No todas las empresas están igual:

  • Microempresas (menos de 10 empleados y <2M€ facturación) están exentas en servicios (no en productos).
  • Carga desproporcionada: ajustes que sean injustificadamente costosos respecto al beneficio se pueden excepcionar, pero con análisis documentado.
  • Infraestructura legacy con alcance limitado puede estar parcialmente excepcionada pero solo con justificación sólida.

“Desproporcionado” no es “no quiero hacerlo” — requiere cálculo documentado.

Qué exige técnicamente

Los requisitos técnicos específicos están en la EN 301 549, el estándar europeo que incorpora WCAG 2.1 AA como referencia base (y WCAG 2.2 ya está disponible).

Los pilares:

  • Perceptible: contenido accesible a distintos sentidos (alt text, subtítulos, contraste).
  • Operable: navegación por teclado, no tiempos forzados, sin contenido que cause convulsiones.
  • Entendible: lenguaje claro, comportamiento predecible, ayuda a errores.
  • Robusto: compatible con tecnologías asistivas presentes y futuras.

Para la mayoría de productos digitales esto significa: HTML semántico, roles ARIA correctos, contraste mínimo 4.5:1 para texto normal, focus-visible en navegación por teclado, subtítulos en vídeo, etc.

Sanciones

Las sanciones dependen del estado miembro. En España, Real Decreto 193/2023:

  • Infracciones leves: hasta 50.000€.
  • Graves: 50.001€ a 400.000€.
  • Muy graves: 400.001€ a 1.000.000€.

Y el riesgo reputacional asociado a auditorías públicas. Ya estamos viendo denuncias de asociaciones de consumidores por accesibilidad — esto crecerá en volumen tras junio 2025.

El error más común

Esperar a mayo 2025. Arreglar problemas de accesibilidad profundos cuesta meses:

  • Auditar es 2-4 semanas para un producto mediano.
  • Refactorizar componentes no accesibles: 2-6 meses.
  • Re-testing y certificación: 2-4 semanas.

A junio 2025 quedan ~16 meses. No es tiempo excesivo si no has empezado.

Un plan de 16 meses realista

Cómo abordarlo por trimestres:

Q1 2024: auditoría completa con herramientas automáticas + revisión manual. – Tools: axe DevTools, WAVE, Lighthouse, pa11y. – Revisión manual de flujos críticos con tecnologías asistivas reales (NVDA, JAWS, VoiceOver). – Output: lista priorizada de issues con estimación de esfuerzo.

Q2-Q3 2024: corrección de issues críticos. – Componentes custom sin soporte ARIA correcto. – Navegación por teclado en toda la app. – Contraste de texto y UI. – Formularios con labels, errors, helpers.

Q4 2024: flujos secundarios y contenido. – Imágenes, vídeos, PDFs. – Documentación y ayuda. – Emails transaccionales accesibles.

Q1 2025: re-auditoría, testing con usuarios reales con discapacidad, documentación de compliance.

Q2 2025: margen para imprevistos y formación de equipos.

Herramientas prácticas

Stack recomendado:

  • axe-core: biblioteca de auditoría que se integra en tests automatizados.
  • WAVE: browser extension para revisión visual.
  • Lighthouse: incluido en Chrome DevTools, útil para CI.
  • pa11y: CLI para incluir en pipelines.
  • Testing manual: NVDA + Firefox en Windows, VoiceOver + Safari en Mac/iOS, TalkBack en Android.

La auditoría automática cubre ~30-40% de issues; el resto necesita humano. Presupuestar ambos.

Impacto más allá de compliance

Accesibilidad bien hecha aporta:

  • SEO: estructura semántica mejora indexación.
  • UX general: diseños accesibles son mejores diseños.
  • Mercado: ~15% de usuarios tienen alguna discapacidad relevante. Producto accesible = TAM más grande.
  • Resiliencia: accesibilidad fuerza disciplina técnica.

No es solo compliance; es inversión con retorno.

Errores típicos

Lo que vemos repetirse:

  • Añadir “aria-label” por todas partes sin entenderlo. Mal ARIA es peor que no ARIA.
  • Depender solo de herramientas automáticas. Cubren un tercio.
  • Ignorar PDFs. Si distribuyes PDFs comerciales, también entran.
  • No formar al equipo. Sin sensibilización, los nuevos desarrollos re-introducen problemas.
  • “Botón de accesibilidad” como solución. Overlay widgets no cumplen EAA y son demandados.

Conclusión

La European Accessibility Act entra en vigor en 16 meses y afecta a más empresas de las que creen. El coste de prepararse es manejable si se empieza ya; el coste de no prepararse escala exponencialmente cerca de la fecha. El enfoque práctico es auditar pronto, priorizar con criterio de severidad, y formar al equipo para que la accesibilidad sea parte de cómo construyen — no una capa final. Las empresas que lo hagan bien tendrán un producto mejor en todos los sentidos, no solo conforme a ley.

Síguenos en jacar.es para más sobre accesibilidad, UX y normativa europea digital.

Entradas relacionadas